security: add network isolation controls and sandboxing documentation (REMOTE-2112)#101
Draft
seemeroland wants to merge 1 commit into
Draft
security: add network isolation controls and sandboxing documentation (REMOTE-2112)#101seemeroland wants to merge 1 commit into
seemeroland wants to merge 1 commit into
Conversation
- Add `network_mode` config field to Docker backend so task containers
can join a custom or restricted Docker network instead of the default
bridge. Accepts any value Docker's --network flag accepts ("none",
named network, "host", or empty for default behavior).
- Wire NetworkMode through config → DockerBackendConfig → HostConfig.NetworkMode
in ContainerCreate. Empty string preserves current behavior (backward compatible).
- Add comprehensive "Security and Sandboxing" section to README covering:
- Isolation model comparison table per backend (Docker, Kubernetes, Direct)
- network_mode configuration with examples (none, named network)
- Egress proxy pattern (HTTP_PROXY/HTTPS_PROXY/NO_PROXY injection)
- Kubernetes NetworkPolicy guidance with task pod label selectors
- Clear statement that the Direct backend provides no network isolation
- Add specs/security-sandboxing/PRODUCT.md and TECH.md documenting the
current security posture, identified enterprise gaps, design rationale
(why no built-in filter), and follow-up opportunities.
Addresses IMC enterprise feedback (REMOTE-2112): autonomous agents need
network-level controls before executing against internal infrastructure.
Co-Authored-By: Oz <oz-agent@warp.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Addresses REMOTE-2112 (IMC enterprise feedback): autonomous agents need network-level security controls before executing against internal infrastructure.
What's in this PR
Code changes (oz-agent-worker):
network_modeconfig field to the Docker backend (backend.docker.network_modein YAML). When set, task containers join the specified Docker network instead of the default bridge. Accepts any value Docker's--networkflag accepts:"none"(no networking), a named network,"host", or empty (default bridge — no behavior change).NetworkModethrough:config.DockerConfig→DockerBackendConfig→container.HostConfig.NetworkModeinContainerCreate. Empty string preserves current behavior (fully backward compatible).Documentation (oz-agent-worker):
## Security and Sandboxingsection in README with:network_modeconfiguration examples (none, named network)HTTP_PROXY/HTTPS_PROXY/NO_PROXYinjection)oz-task-id/oz-worker-idpod labelsSpecs (oz-agent-worker):
specs/security-sandboxing/PRODUCT.md: Current security posture per backend, problem statement, goals/non-goals, detailed behavior invariants, and rationale for not building a built-in filter.specs/security-sandboxing/TECH.md: Implementation details, test plan, risks with mitigations, and follow-up ideas.What Oz provides today (documented)
Why no built-in proxy/filter?
A built-in filtering layer would require
NET_ADMIN, is hard to maintain across kernel versions, and duplicates tools enterprise operators already run (Zscaler, Squid, Cilium Egress Gateway). The proxy pattern and NetworkPolicy compose with existing customer controls.Companion warp-server PR (skill reference update): https://github.com/warpdotdev/warp-server/pull/new/oz-agent/REMOTE-2112/security-sandboxing-skill
Conversation: https://staging.warp.dev/conversation/cfcff22f-d8c9-4e43-b024-fa8ac2860ff1
Run: https://oz.staging.warp.dev/runs/019f4843-cd4b-70e3-8c5f-9ff55f7d490b
This PR was generated with Oz.